The present invention relates generally to the field of software development and, more particularly, to versioning of source code modules and other objects employed for software development.
Modern day software development is typified by sizable development teams comprising software engineers developing various code modules which, when combined, form a computer program. Here, individuals typically create various scripts or source code files which form the individual modules;. Since at any given point in time several individuals may be working on the project, there is a need to coordinate their efforts and manage the source code modules which each individual creates. The general environment, therefore, is one of a team which needs to coordinate it, efforts.
To assist with coordination, various "version control" systems have been developed. Typically, a version control system implements a scheme where various individual programmers "check in" and "check out" source code modules which comprise the project being developed. The check in/check out approach provides modules with a "versioning label" which assists with the task of coordinating the efforts of the individuals which form the team. These versioning labels provide the basic mechanics for a version control system.
Underlying the basic mechanics of version control is a framework for process. In other words, in addition to the mechanics of versioning, there exists an organization which assists in process flow and coordination for the creation of a software product. The mechanics provide the basic operations needed for versioning; the framework provides the structure which facilitates process flow. Structure itself reduces risk, since it lends a repeatable model to the system.
Present-day versioning control systems adopt an approach that is file-based in nature. This approach--one which is based on shared files on a disk storage device--is problematic. In particular, a system employing such an approach is slow and unreliable. Such a system is slow because it employs a centralized control or locking manager through which each request for access must be processed. This represents a bottleneck to system performance. Further, the centralized control leads to difficulty in backing up one's project, thereby leading to decreased system reliability. For instance, it is a difficult task to undertake a "live" backup while source code modules remain checked out. As a result, the backup might actually include an inconsistent view of the system.
Present-day systems essentially serve as "dumb" repositories. In other words, such systems are simple, dumb managers of access rights and, thus, do not lend intelligence to the process. Accordingly, the operations supported are limited in functionality. In particular, a dumb repository cannot capture relationships between files or modules. Such relationships are common between source modules. For instance, a C source file (i.e., .c file) often depends on one or more "header" files (.h) or other "include" files. In fact, a number of arbitrary relationships might exist in a development project, such as a particular module depending on a web page, which in turn points to another object, and so forth and so on, to an arbitrary level. A dumb repository or file system has no facility for capturing these semantic relationships which can exist between source code modules or other objects in a project.
An additional problem with present-day systems is that of lack of scalability. Existing file-based systems do not provide scalability methodology, such as parallel processing. Unlike SQL database systems, for instance, file-based systems do not include an architectural design which support; a high transaction volume--a high number of users accessing a particular object or set of objects. All told, since existing products are all based on file-based technology, they are ill-suited to scale to a level supporting 1,000 or more users at a time.
Another limitation with existing systems is that they are designed to handle only those objects which exist as text files. Today, however, a project under development often comprises objects other than text-based source files. For instance, a product specification might exist as a Microsoft Word (i.e., proprietary) word processing document. Resources for a project might include, on the other hand, various HTML (hypertext markup language) pages having bitmaps. With the explosive growth of multimedia applications and web-based applications, there exists a need for supporting versioning not only of text-based files but also of any arbitrary object which might comprise a project.